Reviewing files that changed from the base of the PR and between 1d4b457 and ebb4ee4.

• constants/requests.ts (2 hunks)
• controllers/oooRequests.ts (4 hunks)
• controllers/requests.ts (3 hunks)
• middlewares/validators/oooRequests.ts (2 hunks)
• middlewares/validators/requests.ts (3 hunks)
• services/oooRequest.ts (1 hunks)
• test/integration/requests.test.ts (1 hunks)
• types/oooRequest.d.ts (2 hunks)

constants/requests.ts (2)

28-29: Well-structured constants for improved request status logging.

These new constants follow the established naming pattern and provide specific log types for already approved or rejected requests, enhancing error handling clarity.

---

46-46: Clear authorization message for OOO request acknowledgment.

This constant effectively communicates the permission requirements, clearly indicating that only super users can acknowledge OOO requests.

test/integration/requests.test.ts (1)

107-109:

❓ Verification inconclusive

Verify behavioral change in duplicate request handling.

The test now expects a successful response (201) with a "REQUEST_CREATED_SUCCESSFULLY" message when creating a duplicate request, rather than the previous error response (400) with "REQUEST_ALREADY_PENDING". This represents a significant change in how duplicate requests are handled.

---

🏁 Script executed:

#!/bin/bash
# Verify if this behavior change is intentional by checking the controller logic
# and related PRs or issue discussions

# Check request creation controller logic
rg -A 10 "REQUEST_ALREADY_PENDING" --type ts

Length of output: 6549

---

Action Required: Confirm Consistency of Duplicate Request Handling Behavior

The integration test in test/integration/requests.test.ts now expects a 201 response with a "REQUEST_CREATED_SUCCESSFULLY" message for duplicate requests. However, our grep results show that other parts of the codebase—such as in test/integration/onboardingExtension.test.ts, controllers/onboardingExtension.ts, and controllers/oooRequests.ts—still rely on the error response with "REQUEST_ALREADY_PENDING" when handling duplicates. Please verify that this behavioral change is intentional and consistent with the overall design. If the change is deliberate, ensure that the updated behavior is clearly documented and that similar endpoints are aligned accordingly.

services/oooRequest.ts (3)

24-59: Well-structured validation function with proper error handling.

The validation function follows good practices by:

1. Checking request type validity
2. Verifying request status isn't already approved or rejected
3. Including appropriate error logging
4. Using consistent error handling patterns

---

87-101: Elegant pattern for conditional message and log type selection.

Good use of array destructuring and a ternary operator to concisely determine the appropriate log type and return message based on the request status.

---

105-122: Comprehensive handling of approved requests.

The function properly creates and adds future status data for approved OOO requests, ensuring the user's status will be updated at the appropriate time.

middlewares/validators/oooRequests.ts (2)

4-4: Updated import to include new type.

The import statement correctly adds the AcknowledgeOOORequest type needed for the new validator function.

---

42-72: Well-structured validator with appropriate validation rules.

The validator:

1. Uses Joi schema validation consistently with other validators
2. Properly validates that status must be APPROVED or REJECTED
3. Makes comment optional but ensures it's not empty if provided
4. Includes appropriate error handling with clear error messages

middlewares/validators/requests.ts (3)

4-5: Approve import additions for OOO request acknowledgment.

The import changes correctly include the new AcknowledgeOOORequest type and acknowledgeOOORequestsValidator function needed for the OOO request acknowledgment feature.

---

133-135: Function parameter type correctly updated to support new OOO acknowledgment flow.

The parameter type expansion to include AcknowledgeOOORequest properly enables the validator to handle both update requests and OOO acknowledgment requests.

---

140-143: Appropriate conditional handling for undefined type.

This new condition correctly handles the case where the request type is undefined, routing it to the OOO acknowledgment validator. This aligns with the design of having acknowledgment requests without a type field.

controllers/oooRequests.ts (5)

1-1: Approve import updates for OOO acknowledgment feature.

The necessary imports have been added to support the new OOO acknowledgment functionality, including the required types, constants, and service functions.

Also applies to: 13-13, 20-20, 22-22

---

36-36: Changed property reference from 'state' to 'status'.

The property reference has been updated from state to status, which aligns with the changes in the OooStatusRequest type. This ensures consistency in how the request state is referenced.

---

127-137: Feature flag implementation for controlled rollout.

The controller properly implements a feature flag check to ensure the feature is only available in development mode. This allows for controlled testing before full release.

---

138-146: Security check for superuser role.

Good implementation of permission checking to ensure only superusers can acknowledge OOO requests, as required by the feature specification.

---

155-158: Error handling follows best practices.

The error handling pattern follows best practices by logging the error and passing it to the next middleware for centralized error handling.

controllers/requests.ts (3)

8-9: Approve import updates for OOO acknowledgment functionality.

The necessary imports have been added to support the OOO acknowledgment feature, including the controller function and required types.

Also applies to: 19-19

---

123-123: Function signature updated to support middleware chain.

Adding the next parameter to the function signature properly enables it to participate in Express middleware chains, which is necessary for error handling in the OOO acknowledgment flow.

---

126-129: Route undefined type requests to OOO acknowledgment controller.

This new conditional logic appropriately routes requests with undefined type to the OOO acknowledgment controller, aligning with the design where acknowledgment requests don't specify a type.

types/oooRequest.d.ts (4)

12-20: Type definitions updated to support OOO request flow.

The updates to the OooStatusRequest type properly reflect the new requirements for OOO requests, including required fields and proper type constraints. The change from state to status aligns with the naming convention being used elsewhere in the codebase.

---

47-49: Feature flag query parameter type definition.

The AcknowledgeOOORequestQuery type correctly extends RequestQuery with the optional dev parameter used for feature flagging.

---

51-54: OOO acknowledgment request body type properly defined.

The body type for acknowledging OOO requests is well-structured with the required status field and optional comment field, matching the validation schema in the middleware.

---

56-61: Complete type definition for the OOO acknowledgment request.

The AcknowledgeOOORequest type properly extends the base Request type with all necessary properties for handling OOO acknowledgments, ensuring type safety throughout the request processing flow.